GGGGLLLL____QQQQUUUUAAAADDDD____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE8888____SSSSGGGGIIIISSSS, GGGGLLLL____QQQQUUUUAAAADDDD____IIIINNNNTTTTEEEENNNNSSSSIIIITTTTYYYY4444____SSSSGGGGIIIISSSS, or
GGGGLLLL____AAAABBBBGGGGRRRR____EEEEXXXXTTTT, GGGGLLLL____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE, and GGGGLLLL____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE____AAAALLLLPPPPHHHHAAAA.
_t_y_p_e Specifies the data type of the pixel data. The following
symbolic values are accepted: GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____BBBBYYYYTTTTEEEE, GGGGLLLL____BBBBYYYYTTTTEEEE,
Texture images are defined with ggggllllTTTTeeeexxxxIIIImmmmaaaaggggeeee4444DDDDSSSSGGGGIIIISSSS. The arguments describe
the parameters of the texture image, such as height, width, depth, extent
(the 4th dimension size), width of the border, level-of-detail number
(see ggggllllTTTTeeeexxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrr), and the internal resolution and format used to
store the image. The last four arguments describe the way the image is
represented in memory, and they are identical to the pixel formats used
for ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss.
If _t_a_r_g_e_t is GGGGLLLL____PPPPRRRROOOOXXXXYYYY____TTTTEEEEXXXXTTTTUUUURRRREEEE____4444DDDD____SSSSGGGGIIIISSSS no data is read from _p_i_x_e_l_s, but
all of the texture image state is recalculated, checked for consistency,
and checked against the implementation's capabilities. If the
implementation cannot handle a texture of the requested texture size, it
will set all of the texture image state to 0 (GGGGLLLL____TTTTEEEEXXXXTTTTUUUURRRREEEE____WWWWIIIIDDDDTTTTHHHH,
GGGGLLLL____TTTTEEEEXXXXTTTTUUUURRRREEEE____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE____SSSSIIIIZZZZEEEE____EEEEXXXXTTTT, and GGGGLLLL____TTTTEEEEXXXXTTTTUUUURRRREEEE____IIIINNNNTTTTEEEENNNNSSSSIIIITTTTYYYY____SSSSIIIIZZZZEEEE____EEEEXXXXTTTT), but no
error will be generated.
If _t_a_r_g_e_t is GGGGLLLL____TTTTEEEEXXXXTTTTUUUURRRREEEE____4444DDDD____SSSSGGGGIIIISSSS, data is read from _p_i_x_e_l_s as a sequence
of signed or unsigned bytes, shorts, or longs, or single-precision
floating-point values, depending on _t_y_p_e. These values are grouped into
sets of one, two, three, or four values, depending on _f_o_r_m_a_t, to form
elements. (Note that if _t_y_p_e is set to GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____BBBBYYYYTTTTEEEE____3333____3333____2222____EEEEXXXXTTTT,
GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____IIIINNNNTTTT____8888____8888____8888____8888____EEEEXXXXTTTT, or GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____IIIINNNNTTTT____11110000____11110000____11110000____2222____EEEEXXXXTTTT then it is
a special case in which all the elements of each group are packed into a
single unsigned byte, unsigned short, or unsigned int. This is described
in ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss.)
Four-dimensional images consist of multiple (perhaps 1) 3D volumes of
image data into a "hypervolume". The size in the 4th dimension can be
called the "extent" of the hypervolume. Analogous to 3D volumes whose
depth ranges from "rear" to "front", the extent of a hypervolume can be
said to range from "near" to "far".
With this in mind, the first element corresponds to the lower-left-rear-
near corner of the texture hypervolume. Subsequent elements progress
left-to-right through the remaining texels in the lowest-rear-near row of
the texture hypervolume, then in successively higher rows of the rear-
near 2D slice of the texture hypervolume, then in successively frontal 2D
slices and farther 3D volumes of the texture hypervolume. The final
element corresponds to the upper-right-front-far corner of the texture
hypervolume.
When GGGGLLLL____IIIINNNNTTTTEEEERRRRLLLLAAAACCCCEEEE____SSSSGGGGIIIIXXXX is enabled, only rows (0,2,4,...) of each S-T
slice (where the border is considered part of the slice) are defined.
Rows (1,3,5,...) are left undefined and can only be defined using
ggggllllTTTTeeeexxxxSSSSuuuubbbbIIIImmmmaaaaggggeeee4444DDDDSSSSGGGGIIIISSSS. Note, that when GGGGLLLL____IIIINNNNTTTTEEEERRRRLLLLAAAACCCCEEEE____SSSSGGGGIIIIXXXX is enabled the
total height (i.e., the height of interior texture image plus twice the
border) of the defined texture is 2*height.
Each element of _p_i_x_e_l_s is converted to an RGBA element according to
_f_o_r_m_a_t, as detailed below. Except for GGGGLLLL____CCCCOOOOLLLLOOOORRRR____IIIINNNNDDDDEEEEXXXX, after the
conversion to RGBA, each component is multiplied by the signed scale
factor GGGGLLLL____cccc____SSSSCCCCAAAALLLLEEEE, added to the signed bias GGGGLLLL____cccc____BBBBIIIIAAAASSSS, and clamped to the
range [0,1], where cccc is RRRREEEEDDDD, GGGGRRRREEEEEEEENNNN, BBBBLLLLUUUUEEEE, or AAAALLLLPPPPHHHHAAAA, respectively (see
the value and sign of GGGGLLLL____IIIINNNNDDDDEEEEXXXX____SSSSHHHHIIIIFFFFTTTT, and added to
GGGGLLLL____IIIINNNNDDDDEEEEXXXX____OOOOFFFFFFFFSSSSEEEETTTT (see ggggllllPPPPiiiixxxxeeeellllTTTTrrrraaaannnnssssffffeeeerrrr). The resulting index is
support that resolution (The formats of GGGGLLLL____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE, GGGGLLLL____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE____AAAALLLLPPPPHHHHAAAA,
GGGGLLLL____RRRRGGGGBBBB, and GGGGLLLL____RRRRGGGGBBBBAAAA must be supported.) When a resolution and storage
format is specified, the implementation will update the texture state to
provide the best match to the requested resolution. The
GGGGLLLL____PPPPRRRROOOOXXXXYYYY____TTTTEEEEXXXXTTTTUUUURRRREEEE____4444DDDD____SSSSGGGGIIIISSSS target can be used to try a resolution and
format. The implementation will compute its best match for the requested
storage resolution and format; this state can then be queried using
A one-component texture image uses only the red component of the RGBA
color extracted from _p_i_x_e_l_s. A two-component image uses the R and A
values. A three-component image uses the R, G, and B values. A four-
component image uses all of the RGBA components.
The mapping of components from the canonical RGBA to the internal storage
formats that begin with GGGGLLLL____DDDDUUUUAAAALLLL____ and GGGGLLLL____QQQQUUUUAAAADDDD____ needs to be clarified.
There are three cases. The first case is for the GGGGLLLL____DDDDUUUUAAAALLLL____ formats that
are groups of GGGGLLLL____AAAALLLLPPPPHHHHAAAA, GGGGLLLL____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE, and GGGGLLLL____IIIINNNNTTTTEEEENNNNSSSSIIIITTTTYYYY. The R value goes
to the first group while the A value goes to the second group. The
second case is for the GGGGLLLL____DDDDUUUUAAAALLLL____ formats that are groups of
GGGGLLLL____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE____AAAALLLLPPPPHHHHAAAA. The R and G values go to the first group while the B
and A values go to the second group. The third case is for the GGGGLLLL____QQQQUUUUAAAADDDD____
formats. The R value goes to the first group, the G value to the second
group, the B value to the third group, and the A value to the fourth
group.
NNNNOOOOTTTTEEEESSSS
Texturing has no effect in color index mode.
The texture image can be represented by the same data formats and types
as the pixels in a ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss command, except that formats
GGGGLLLL____SSSSTTTTEEEENNNNCCCCIIIILLLL____IIIINNNNDDDDEEEEXXXX and GGGGLLLL____DDDDEEEEPPPPTTTTHHHH____CCCCOOOOMMMMPPPPOOOONNNNEEEENNNNTTTT cannot be used, and type
GGGGLLLL____BBBBIIIITTTTMMMMAAAAPPPP cannot be used. ggggllllPPPPiiiixxxxeeeellllSSSSttttoooorrrreeee and ggggllllPPPPiiiixxxxeeeellllTTTTrrrraaaannnnssssffffeeeerrrr modes affect
texture images in exactly the way they affect ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss.
A texture image with zero height, width, depth, or extent indicates the
null texture. If the null texture is specified for level-of-detail 0, it
is as if texturing were disabled.
ggggllllTTTTeeeexxxxIIIImmmmaaaaggggeeee4444DDDDSSSSGGGGIIIISSSS is part of the EEEEXXXXTTTT____tttteeeexxxxttttuuuurrrreeee3333dddd extension.
If _t_y_p_e is set to GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____BBBBYYYYTTTTEEEE____3333____3333____2222____EEEEXXXXTTTT,
GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____IIIINNNNTTTT____8888____8888____8888____8888____EEEEXXXXTTTT, or GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____IIIINNNNTTTT____11110000____11110000____11110000____2222____EEEEXXXXTTTT and the
EEEEXXXXTTTT____ppppaaaacccckkkkeeeedddd____ppppiiiixxxxeeeellllssss extension is not supported then a GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____EEEENNNNUUUUMMMM error
is generated.
See ggggllllIIIInnnnttttrrrroooo for more information on using extensions.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____VVVVAAAALLLLUUUUEEEE is generated if _i_n_t_e_r_n_a_l_f_o_r_m_a_t is not an accepted value.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____VVVVAAAALLLLUUUUEEEE is generated if _w_i_d_t_h, _h_e_i_g_h_t, _d_e_p_t_h, or _s_i_z_e_4_d is less
than zero or greater than GGGGLLLL____MMMMAAAAXXXX____4444DDDD____TTTTEEEEXXXXTTTTUUUURRRREEEE____SSSSIIIIZZZZEEEE____SSSSGGGGIIIISSSS, when _w_i_d_t_h, _d_e_p_t_h,
or _s_i_z_e_4_d cannot be represented as 2**k+2*border for some integer k, or
when _h_e_i_g_h_t cannot be represented as 2**k+I*border, where I is 2 when
GGGGLLLL____IIIINNNNTTTTEEEERRRRLLLLAAAACCCCEEEE____SSSSGGGGIIIIXXXX is disabled and 1 otherwise.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____VVVVAAAALLLLUUUUEEEE is generated if _b_o_r_d_e_r is not 0 or 1.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN is generated if ggggllllTTTTeeeexxxxIIIImmmmaaaaggggeeee4444DDDDSSSSGGGGIIIISSSS is executed between
the execution of ggggllllBBBBeeeeggggiiiinnnn and the corresponding execution of ggggllllEEEEnnnndddd.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____VVVVAAAALLLLUUUUEEEE is generated if the implementation cannot accomodate a
ggggllllIIIIssssEEEEnnnnaaaabbbblllleeeedddd with argument GGGGLLLL____TTTTEEEEXXXXTTTTUUUURRRREEEE____4444DDDD____SSSSGGGGIIIISSSS
ggggllllGGGGeeeettttTTTTeeeexxxxLLLLeeeevvvveeeellllPPPPaaaarrrraaaammmmeeeetttteeeerrrr with a first argument of GGGGLLLL____PPPPRRRROOOOXXXXYYYY____TTTTEEEEXXXXTTTTUUUURRRREEEE____4444DDDD____SSSSGGGGIIIISSSS
and a third argument of GGGGLLLL____TTTTEEEEXXXXTTTTUUUURRRREEEE____RRRREEEEDDDD____SSSSIIIIZZZZEEEE____EEEEXXXXTTTT,
GGGGLLLL____TTTTEEEEXXXXTTTTUUUURRRREEEE____DDDDEEEEPPPPTTTTHHHH____EEEEXXXXTTTT, GGGGLLLL____TTTTEEEEXXXXTTTTUUUURRRREEEE____BBBBOOOORRRRDDDDEEEERRRR, or GGGGLLLL____TTTTEEEEXXXXTTTTUUUURRRREEEE____CCCCOOOOMMMMPPPPOOOONNNNEEEENNNNTTTTSSSS.
The EEEEXXXXTTTT____ppppaaaacccckkkkeeeedddd____ppppiiiixxxxeeeellllssss extension is not supported on RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee,
RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee2222, and VVVVTTTTXXXX systems.
On HHHHiiiigggghhhh IIIImmmmppppaaaacccctttt and MMMMaaaaxxxxiiiimmmmuuuummmm IIIImmmmppppaaaacccctttt systems the number of bits per
component, represented internally, is the same for all components and
will be 4, 8, or 12 bits per component. All specified internal formats
will receive an equal or greater representation in this scheme, up to the
12-bit limit. HHHHiiiigggghhhh IIIImmmmppppaaaacccctttt and MMMMaaaaxxxxiiiimmmmuuuummmm IIIImmmmppppaaaacccctttt on Indigo2 systems do not
support texture internal formats of the type GGGGLLLL____IIIINNNNTTTTEEEENNNNSSSSIIIITTTTYYYY or GGGGLLLL____AAAALLLLPPPPHHHHAAAA,
although HHHHiiiigggghhhh IIIImmmmppppaaaacccctttt and MMMMaaaaxxxxiiiimmmmuuuummmm IIIImmmmppppaaaacccctttt on Octane systems do support
